Repository navigation
fix: flaky jest test - #2208
fix: flaky jest test#2208cimigree wants to merge 2 commits into
Conversation
…back to the app and block the add observation button.
|
Would the problem be solved if we don't persist any of the stores in this helper? The entire point of using zustand stores in context is so that we could not uses persisted stores in tests, but I think whne implementing we just forgot. Im not sure if this would fix the problem, but if it does i think we should just make ALL the stores in the text not persist so we dont have to worry about states outside of the tests? |
Yes and no. I am not sure about not persisting all the stores, but I know we can not persist, ie change to I tried that out the same way I tried out my fix and it also worked. Want me to switch to that? |
For this fix, yes I think that is the preferred solution. As follow up, i think we should also make persist false for the rest of them as well. |
closes #2152
Which test
The same test was failing on Frontend CI.
"Unable to find an element with
testID: MAIN.add-observation-btninsrc/frontend/screens/ObservationFields/index.test.tsxIt was usually
renders empty when tagValue is undefined/nullBad news: It has failed many times since October 2 (I think 16 or more)
Good news: It was the only failure in that time
Why
The tests leave an unsaved draft observation behind, and it is still in storage when the next test starts. The map screen sees the draft and opens New Observation, as it does when someone returns to the app with an unfinished observation. That hides the add observation button, so the test can't find it. This is a timing problem, which is probably why it only showed up on CI. On a fast machine, the test finds the button before the old observation pops up (locally). On CI it takes longer to get to the map screen and by then the old observation is blocking the button.
The fix
Clears an observation after tests so it doesn't pop up when coming back to the app and block the add observation button.